Linux Cubed Series 7: Sunsite

home *** CD-ROM | disk | FTP | other *** search

/ Linux Cubed Series 7: Sunsite / Linux Cubed Series 7 - Sunsite Vol 1.iso / system / filesyst / ext2 / ext2ed-0.000 / ext2ed-0 / ext2ed-0.1 / doc / user-guide-0.1.sgml < prev

Wrap

SGML Document | 1995-08-23 | 42KB

<!doctype linuxdoc system>     <article> <title>EXT2ED - The Extended-2 filesystem editor - User's guide <author>Gadi Oxman, tgud@tochnapc2.technion.ac.il <date>v0.1, August 3 1995 <abstract> This is only the initial version of this document. It may be unclear at some places. Please send me feedback with anything regarding to it. </abstract> <toc>  <sect>About EXT2ED documentation The EXT2ED documentation consists of three parts: <itemize> <item> The ext2 filesystem overview. <item> The EXT2ED user's guide. <item> The EXT2ED design and implementation. </itemize> If you intend to used EXT2ED, I strongly suggest that you would be familiar with the material presented in the <tt>ext2 filesystem overview</> as well. If you also intend to browse and modify the source code, I suggest that you will also read the article <tt>The EXT2ED design and implementation</>, as it provides a general overview of the structure of my source code. <sect>Introduction EXT2ED is a "disk editor" for the ext2 filesystem. Its purpose is to show you the internal structures of the ext2 filesystem in an rather intuitive and logical way, so that it will be easier to "travel" between the various internal filesystem structures. <sect>Basic concepts in EXT2ED Two basic concepts in EXT2ED are <tt>commands</> and <tt>types</>. EXT2ED is object-oriented in the sense that it defines objects in the filesystem, like a <tt>super-block</> or a <tt>directory</>. An object is something which "knows" how to handle some aspect of the filesystem. Your interaction with EXT2ED is done through <tt>commands</> which EXT2ED accepts. There are three levels of commands: <itemize> <item> General Commands <item> Extended-2 Filesystem general commands <item> Type specific commands </itemize> The General commands are always available. The ext2 general commands are available only when editing an ext2 filesystem. The Type specific commands are available when editing a specific object in the filesystem. Each object typically comes with its own set of internal variables, and its own set of commands, which are fine tuned handle the corresponding structure in the filesystem. <sect>Running EXT2ED Running EXT2ED is as simple as typing <tt>ext2ed</> from the shell prompt. There are no command line switches. When first run, EXT2ED parses its configuration file, <tt>ext2ed.conf</>. This file must exist. When the configuration file processing is done, EXT2ED screen should appear on the screen, with the command prompt <tt>ext2ed></> displayed. <sect>EXT2ED user interface EXT2ED uses the ncurses</> library for screen management. Your screen will be divided into four parts, from top to bottom: <itemize> <item> Title window <item> Status window <item> Main editing window <item> Command window </itemize> The title window just displays the current version of EXT2ED. The status window will display various information regarding the state of the editing at this point. The main editing window is the place at which the actual data will be shown. Almost every command will cause some display at this window. This window, as opposed to the three others, is of variable length - You always look at one page of it. The current page and the total numbers of pages at this moment is displayed at the status window. Moving between pages is done by the use of the <tt>pgdn</> and <tt>pgup</> commands. The command window is at the bottom of the screen. It always displays a command prompt <tt>ext2ed></> and allows you to type a command. Feedback about the commands entered is displayed to this window also. EXT2ED uses the readline</> library while processing a command line. All the usual editing keys are available. Each entered command is placed into a history of commands, and can be recalled later. Command Completion is also supported - Just start to type a command, and press the completion key. Pressing <tt>enter</> at the command window, without entering a command, recalls the last command. This is useful when moving between close entries, in the <tt>next</> command, for example. <sect>Getting started <sect1>A few precautions EXT2ED is a tool for filesystem <tt>editing</>. As such, it can be <tt>dangerous</>. The summary to the subsections below is that <tt>You must know what you are doing</>. <sect2><label id="mounted_ref">A mounted filesystem EXT2ED is not designed to work on a mounted filesystem - It is complicated enough as it is; I didn't even try to think of handling the various race conditions. As such, please respect the following advice: <tt>Do not use EXT2ED on a mounted filesystem !</> EXT2ED will not allow write access to a mounted filesystem. Although it is fairly easy to change EXT2ED so that it will be allowed, I hereby request again- EXT2ED is not designed for that action, and will most likely corrupt data if used that way. Please don't do that. Concerning read access, I chose to leave the decision for the user through the configuration file option <tt>AllowMountedRead</>. Although read access on a mounted partition will not do any damage to the filesystem, the data displayed to you will not be reliable, and showing you incorrect information may be as bad as corrupting the filesystem. However, you may still wish to do that. <sect2>Write access Considering the obvious sensitivity of the subject, I took the following actions: <enum> <item> EXT2ED will always start with a read-only access. Write access mode needs to be specifically entered by the <tt>enablewrite</> command. Until this is done, no write will be allowed. Write access can be disabled at any time with <tt>disablewrite</>. When <tt>enablewrite</> is issued, the device is reopened in read-write mode. Needless to say, the device permissions should allow that. <item> As a second level of protection, you can disallow write access in the configuration file by using the <tt>AllowChanges off</> configuration option. In this case, the <tt>enablewrite</> command will be refused. <item> When write access is enabled, the data will never change immediately. Rather, a specific <tt>writedata</> command is needed to update the object in the disk with the changed object in memory. <item> In addition, A logging option is provided through the configuration file options <tt>LogChanges</> and <tt>LogFile</>. With logging enabled, each change to the disk will be logged at a very primitive level - A hex dump of the original data and of the new written data. The log file will be a text file which is easily readable, and you can make use of it to undo any changes which you made (EXT2ED doesn't make use of the log file for that purpose, it just logs the changes). </enum> Please remember that this is only the initial release of EXT2ED, and it is not very much tested - It is reasonable to assume that <tt>there are bugs</>. However, the logging option above can offer protection even from this unfortunate case. Therefor, I highly recommend that at least when first working with EXT2ED, the logging option will be enabled, despite the disk space which it consumes. <sect1><label id="help_ref">The help command When loaded, EXT2ED will show a short help screen. This help screen can always be retrieved by the command <tt>help</>. The help screen displays a list of all the commands which are available at this point. At startup, only the <tt>General commands</> are available. This will change with time, since each object has its own commands. Thus, commands which are available now may not be available later. Using <tt>help</> command</> will display additional information about the specific command command</>. <sect1><label id="setdevice_ref">The setdevice command The first command that is usually entered to EXT2ED is the <tt>setdevice</> command. This command simply tells EXT2ED on which device the filesystem is present. For example, suppose my ext2 filesystem is on the first partition of my ide disk. The command will be: <tscreen><verb> setdevice /dev/hda1 </verb></tscreen> The following actions will take place in the following order: <enum> <item> EXT2ED will check if the partition is mounted. If the partition is mounted (<tt>highly not recommended</>), the accept/reject behavior will be decided by the configuration file. Cross reference section <ref id="mounted_ref">. <item> The specified device will be opened in read-only mode. The permissions of the device should be set in a way that allows you to open the device for read access. <item> Autodetection of an ext2 filesystem will be made by searching for the ext2 magic number in the main superblock. <item> In the case of a successful recognition of an ext2 filesystem, the ext2 filesystem specific commands and the ext2 specific object definitions will be registered. The object definitions will be read at run time from a file specified by the configuration file. In case of a corrupted ext2 filesystem, it is quite possible that the main superblock is damaged and autodetection will fail. In that case, use the configuration option <tt>ForceExt2 on</>. This is not the default case since EXT2ED can be used at a lower level to edit a non-ext2 filesystem. <item> In a case of a successful autodetection, essential information about the filesystem such as the block size will be read from the superblock, unless the used overrides this behavior with an configuration option (not recommended). In that case, the parameters will be read from the configuration file. In a case of an autodetection failure, the essential parameters will be read from the configuration file. </enum> Assuming that you are editing an ext2 filesystem and that everything goes well, you will notice that additional commands are now available in the help screen, under the section <tt>ext2 filesystem general commands</>. In addition, EXT2ED now recognizes a few objects which are essential to the editing of an ext2 filesystem. <sect>Two levels of usage <sect1>Low level usage This section explains what EXT2ED provides even when not editing an ext2 filesystem. Even at this level, EXT2ED is more than just a hex editor. It still allows definition of objects and variables in run time through a user file, although of-course the objects will not have special fine tuned functions connected to them. EXT2ED will allow you to move in the filesystem using <tt>setoffset</>, and to apply an object definition on a specific place using <tt>settype</> type</>. From this point and on, the object will be shown <tt>in its native form</> - You will see a list of the variables rather than just a hex dump, and you will be able to change each variable in the intuitive form <tt>set variable=value</>. To define objects, use the configuration option <tt>AlternateDescriptors</>. There are now two forms of editing: <itemize> <item> Editing without a type. In this case, the disk block will be shown as a text+hex dump, and you will be able to move along and change it. <item> Editing with a type. In this case, the object's variables will be shown, and you will be able to change each variable in its native form. </itemize> <sect1>High level usage EXT2ED was designed for the editing of the ext2 filesystem. As such, it "understands" the filesystem structure to some extent. Each object now has special fine tuned 'C' functions connected to it, which knows how to display it in an intuitive form, and how the object fits in the general design of the ext2 filesystem. It is of-course much easier to use this type of editing. For example: <tscreen> Issue group 2</> to look at the main copy of the third group block descriptor. With gocopy 1</> you can move to its first backup copy, and with inode</> you can start editing the inode table of the above group block. From here, if the inode corresponds to a file, you can use file</> to edit the file in a "continuous" way, using nextblock</> to pass to its next block, letting EXT2ED following by itself the direct blocks, indirect blocks, ..., while still preserving the actual view of the exact block usage of the file. </tscreen> The point is that the "tour" of the filesystem will now be synchronic rather than asynchronic - Each object has the "links" to pass between connected logical structures, and special fine-tuned functions to deal with it. <sect>General commands I will now start with a systematic explanation of the general commands. Please feel free to experiment, but take care when using the <tt>enablewrite</> command. Whenever a command syntax is specified, arguments which are optional are enclosed with square brackets. Please note that in EXT2ED, each command can be overridden by a specific object to provide special fine-tuned functionality. In general, I was attempting to preserve the similarity between those functions, which are accessible by the same name. <sect1><label id="disablewrite_ref">disablewrite <tscreen><verb> Syntax: disablewrite </verb></tscreen> <tt>disablewrite</> is used to reopen the device with read-only access. When first running EXT2ED, the device is opened in read-only mode, and an explicit <tt>enablewrite</> is required for write access. When finishing with changing, a <tt>disablewrite</> is recommended for safety. Cross reference section <ref id="disablewrite_ref">. <sect1><label id="enablewrite_ref">enablewrite <tscreen><verb> Syntax: enablewrite </verb></tscreen> <tt>enablewrite</> is used to reopen the device with read-write access. When first running EXT2ED, the device is opened in read-only mode, and an explicit <tt>enablewrite</> is required for write access. <tt>enablewrite</> will fail if write access is disabled from the configuration file by the <tt>AllowChanges off</> configuration option. Even after <tt>enablewrite</>, an explicit <tt>writedata</> is required to actually write the new data to the disk. When finishing with changing, a <tt>disablewrite</> is recommended for safety. Cross reference section <ref id="enablewrite_ref">. <sect1>help <tscreen><verb> Syntax: help [command] </verb></tscreen> The <tt>help</> command is described at section <ref id="help_ref">. <sect1><label id="next_ref">next <tscreen><verb> Syntax: next [number] </verb></tscreen> This section describes the general command</> <tt>next</>. <tt>next</> is overridden by several types in EXT2ED, to provide fine-tuned functionality. The <tt>next general command</> behavior is depended on whether you are editing a specific object, or none. <itemize> <item> In the case where Type is <tt>none</> (The current type is showed on the status window by the <tt>show</> command), <tt>next</> passes to the next number</> bytes in the current edited block. If number</> is not specified, number=1</> is assumed. <item> In the case where Type is defined, the <tt>next</> commands assumes that you are editing an array of objects of that type, and the <tt>next</> command will just pass to the next entry in the array. If number</> is defined, it will pass number</> entries ahead. </itemize> <sect1><label id="pgdn_ref">pgdn <tscreen><verb> Syntax: pgdn </verb></tscreen> Usually the edited data doesn't fit into the visible main window. In this case, the status window will indicate that there is more to see "below" by the message <tt>Page x of y</>. This means that there are y</> pages total, and you are currently viewing the x</> page. With the <tt>pgdn</> command, you can pass to the next available page. <sect1>pgup <tscreen><verb> Syntax: pgup </verb></tscreen> <tt>pgup</> is the opposite of <tt>pgdn</> - It will pass to the previous page. Cross reference section <ref id="pgdn_ref">. <sect1>prev <tscreen><verb> Syntax: prev [number] </verb></tscreen> <tt>prev</> is the opposite of <tt>next</>. Cross reference section <ref id="next_ref">. <sect1><label id="recall_ref">recall <tscreen><verb> Syntax: recall object </verb></tscreen> <tt>recall</> is the opposite of <tt>remember</>. It will place you at the place you where when saving the object position and type information. Cross reference section <ref id="remember_ref">. <sect1>redraw <tscreen><verb> Syntax: redraw </verb></tscreen> Sometimes the screen display gets corrupted. I still have problems with this. The <tt>redraw</> command simply redraws the entire display screen. <sect1><label id="remember_ref">remember <tscreen><verb> Syntax: remember object </verb></tscreen> EXT2ED provides you <tt>memory</> of objects; While editing, you may reach an object which you will like to return to later. The <tt>remember</> command will store in memory the current place and type of the object. You can return to the object by using the <tt>recall</> command. Cross reference section <ref id="recall_ref">. <tt>Note:</> <itemize> <item> When remembering a <tt>file</> or a <tt>directory</>, the corresponding inode will be saved in memory. The basic reason is that the inode is essential for finding the blocks of the file or the directory. </itemize> <sect1>set <tscreen><verb> Syntax: set [text || hex] arg1 [arg2 arg3 ...] or Syntax: set variable=value </verb></tscreen> The <tt>set</> command is used to modify the current data. The <tt>set general command</> behavior is depended on whether you are editing a specific object, or none. <itemize> <item> In the case where Type is <tt>none</>, the first syntax should be used. The set command affects the data starting at the current highlighted position in the edited block. <itemize> <item> When using the <tt>set hex</> command, a list of hexadecimal bytes should follow. <item> When using the <tt>set text</> command, it should be followed by a text string. </itemize> Examples: <tscreen><verb> set hex 09 0a 0b 0c 0d 0e 0f set text Linux is just great ! </verb></tscreen> <item> In the case where Type is defined, the second syntax should be used. The set commands just sets the variable variable</> with the value value</>. </itemize> In any case, the data is only changed in memory. For an actual update to the disk, use the <tt>writedata</> command. <sect1>setdevice <tscreen><verb> Syntax: setdevice device </verb></tscreen> The <tt>setdevice</> command is described at section <ref id="setdevice_ref">. <sect1>setoffset <tscreen><verb> Syntax: setoffset [block || type] [+|-]offset </verb></tscreen> The <tt>setoffset</> command is used to move asynchronically inside the file system. It is considered a low level command, and usually should not be used when editing an ext2 filesystem, simply because movement is better utilized through the specific ext2 commands. The <tt>offset</> is in bytes, and meanwhile should be positive and smaller than 2GB. Use of the <tt>block</> modifier changes the counting unit to block. Use of the <tt>+ or -</> modifiers signals that the offset is relative to the current position. use of the <tt>type</> modifier is allowed only with relative offset. This modifier will multiply the offset by the size of the current type. <sect1>settype <tscreen><verb> Syntax: settype type || [none | hex] </verb></tscreen> The <tt>settype</> command is used to move apply the object definitions of the type type</> on the current position. It is considered a low level command and usually should not be used when editing an ext2 filesystem since EXT2ED provides better tools. It is of-course very useful when editing a non-ext2 filesystem and using user-defined objects. When type</> is hex</> or none</>, the data will be displayed as a hex and text dump. <sect1>show <tscreen><verb> Syntax: show </verb></tscreen> The <tt>show</> command will show the data of the current object at the current position on the main display window. It will also update the status window with type specific information. It may be necessary to use <tt>pgdn</> and <tt>pgup</> to view the entire data. <sect1>writedata <tscreen><verb> Syntax: writedata </verb></tscreen> The <tt>writedata</> command will update the disk with the object data that is currently in memory. This is the point at which actual change is made to the filesystem. Without this command, the edited data will not have any effect. Write access should be allowed for a successful update. <sect>Editing an ext2 filesystem In order to edit an ext2 filesystem, you should, of course, know the structure of the ext2 filesystem. If you feel that you lack some knowledge in this area, I suggest that you do some of the following: <itemize> <item> Read the supplied ext2 technical information. I tried to summarize the basic information which is needed to get you started. <item> Get the slides that Remy Card (The author of the ext2 filesystem) prepared concerning the ext2 filesystem. <item> Read the kernel sources. </itemize> At this point, you should be familiar with the following terms: <tt>block, inode, superblock, block groups, block allocation bitmap, inode allocation bitmap, group descriptors, file, directory.</>Most of the above are objects in EXT2ED. When editing an ext2 filesystem it is recommended that you use the ext2 specific commands, rather then the general commands <tt>setoffset</> and <tt>settype</>, mainly because: <enum> <item> In most cases it will be unreliable, and will display incorrect information. Sometimes in order to edit an object, EXT2ED needs the information of some other related objects. For example, when editing a directory, EXT2ED needs access to the inode of the edited directory. Simply setting the type to a directory <tt>will be unreliable</>, since the object assumes that you passed through its inode to reach it, and expects this information, which isn't initialized if you directly set the type to a directory. <item> EXT2ED offers far better tools for handling the ext2 filesystem using the ext2 specific commands. </enum> <sect>ext2 general commands The <tt>ext2 general commands</> are available only when you are editing an ext2 filesystem. They are <tt>general</> in the sense that they are not specific to some object, and can be invoked anytime. <sect1><label id="general_superblock">super <tscreen><verb> Syntax: super </verb></tscreen> The <tt>super</> command will "bring you" to the main superblock copy. It will automatically set the object type to <tt>ext2_super_block</>. Then you will be able to view and edit the superblock. When you are in the superblock, other commands will be available. <sect1>group <tscreen><verb> Syntax: group [number] </verb></tscreen> The <tt>group</> command will "bring you" to the main copy of the number</> group descriptor. It will automatically set the object type to <tt>ext2_group_desc</>. Then you will be able to view and edit the group descriptor entry. When you are there, other commands will be available. <sect1>cd <tscreen><verb> Syntax: cd path </verb></tscreen> The <tt>cd</> command will let you travel in the filesystem in the nice way that the mounted filesystem would have let you. The <tt>cd</> command is a complicated command. Although it may sound simple at first, an implementation of a typical cd requires passing through the group descriptors, inodes, directory entries, etc. For example: The innocent cd /usr command can be done by using more primitive EXT2ED commands in the following way (It is implemented exactly this way): <enum> <item> Using <tt>group 0</> to go to the first group descriptor. <item> Using <tt>inode</> to get to the Bad blocks inode. <item> Using <tt>next</> to pass to the root directory inode. <item> Using <tt>dir</> to see the directory. <item> Using <tt>next</> until we find the directory usr. <item> Using <tt>followinode</> to pass to the inode corresponding to usr. <item> Using <tt>dir</> to see the directory of /usr. </enum> And those commands aren't that primitive; For example, the tracing of the blocks which belong to the root directory is done automatically by the dir command behind the scenes, and the followinode command will automatically "run" to the correct group descriptor in order to find the required inode. The path to the <tt>general cd</> command needs to be a full pathname - Starting from <tt>/</>. The <tt>cd</> command stops at the last reachable point, which can be a directory entry, in which case the type will be set to <tt>dir</>, or an inode, in which case the type will be set to <tt>ext2_inode</>. Symbolic links (Only fast symbolic links, meanwhile) are automatically followed (if they are not across filesystems, of-course). If the type is set to <tt>dir</>, you can use a path relative to the "current directory". <sect>The superblock The superblock can always be reached by the ext2 general command <tt>super</>. Cross reference section <ref id="general_superblock">. The status window will show you which copy of the superblock copies you are currently editing. The main data window will show you the values of the various superblock variables, along with some interpretation of the values. Data can be changed with the <tt>set</> and <tt>writedata</> commands. <tscreen><verb> For example, set s_r_blocks_count=1400 will reserve 1400 blocks for root. </verb></tscreen> <sect1>gocopy <tscreen><verb> Syntax: gocopy number </verb></tscreen> The <tt>gocopy</> command will "bring you" to the backup copy number</> of the superblock copies. <tt>gocopy 0</>, for example, will bring you to the main copy. <sect1>setactivecopy <tscreen><verb> Syntax: setactivecopy </verb></tscreen> The <tt>setactivecopy</> command will copy the contents of the current superblock copy onto the contents of the main copy. It will also switch to editing of the main copy. No actual data is written to disk, of-course, until you issue the <tt>writedata</> command. <sect>The group descriptors The group descriptors can be edited by the <tt>group</> command. The status window will indicate the current group descriptor, the total number of group descriptors (and hence of group blocks), and the backup copy number. The main data window will just show you the values of the various variables. Basically, you can use the <tt>next</> and <tt>prev</> commands, along with the <tt>set</> command, to modify the group descriptors. The group descriptors object is a junction, from which you can reach: <itemize> <item> The inode table of the corresponding block group (the <tt>inode</> command) <item> The block allocation bitmap (the <tt>blockbitmap</> command) <item> The inode allocation bitmap (the <tt>inodebitmap</> command) </itemize> <sect1>blockbitmap <tscreen><verb> Syntax: blockbitmap </verb></tscreen> The <tt>blockbitmap</> command will let you edit the block bitmap allocation block of the current group block. <sect1>entry <tscreen><verb> Syntax: entry number </verb></tscreen> The <tt>entry</> command will move you to the number</> group descriptor in the group descriptors table. <sect1>inode <tscreen><verb> Syntax: inode </verb></tscreen> The <tt>inode</> command will pass you to the first inode in the current group block. <sect1>inodebitmap <tscreen><verb> Syntax: inodebitmap </verb></tscreen> The <tt>inodebitmap</> command will let you edit the inode bitmap allocation block of the current group block. <sect1>next <tscreen><verb> Syntax: next [number] </verb></tscreen> The <tt>next</> command will pass to the next number</> group descriptor. If number</> is omitted, number=1</> is assumed. <sect1>prev <tscreen><verb> Syntax: prev [number] </verb></tscreen> The <tt>prev</> command will pass to the previous number</> group descriptor. If number</> is omitted, number=1</> is assumed. <sect1>setactivecopy <tscreen><verb> Syntax: setactivecopy </verb></tscreen> The <tt>setactivecopy</> command copies the contents of the current group descriptor, to its main copy. The updated main copy will then be shown. No actual change is made to the disk until you issue the <tt>writedata</> command. <sect>The inode An inode can be reached by the following two ways: <itemize> <item> Using <tt>inode</> from the corresponding group descriptor. <item> Using <tt>followinode</> from a directory entry. <item> Using the <tt>cd</> command with the pathname to the file. For example, <tt>cd /usr/src/ext2ed/ext2ed.h</> </itemize> The status window will indicate: <itemize> <item> The current global inode number. <item> The total total number of inodes. <item> On which block group the inode is allocated. <item> The total number of inodes in this group block. <item> The index of the current inode in the current group block. <item> The type of the inode (file, directory, special, etc). </itemize> The main data window, in addition to the list of variables, will contain some interpretations on the right side. If the inode corresponds to a file, you can use the <tt>file</> command to edit the file. If the inode is an inode of a directory, you can use the <tt>dir</> command to edit the directory. <sect1>dir <tscreen><verb> Syntax: dir </verb></tscreen> If the inode mode corresponds to a directory (shown on the status window), you can enter directory mode editing by using <tt>dir</>. <sect1>entry <tscreen><verb> Syntax: entry number </verb></tscreen> The <tt>entry</> command will move you to the number</> inode in the current inode table. <sect1>file <tscreen><verb> Syntax: file </verb></tscreen> If the inode mode corresponds to a file (shown on the status window), you can enter file mode editing by using <tt>file</>. <sect1>group <tscreen><verb> Syntax: group </verb></tscreen> The <tt>group</> command is used to go to the group descriptor of the current group block. <sect1>next <tscreen><verb> Syntax: next [number] </verb></tscreen> The <tt>next</> command will pass to the next number</> inode. If number</> is omitted, number=1</> is assumed. <sect1>prev <tscreen><verb> Syntax: prev [number] </verb></tscreen> The <tt>prev</> command will pass to the previous number</> inode. If number</> is omitted, number=1</> is assumed. <sect>The file When editing a file, EXT2ED offers you a both a continuous and a true fragmented view of the file - The file is still shown block by block with the true block number at each stage and EXT2ED offers you commands which allow you to move between the <tt>file blocks</>, while finding the allocated blocks by using the inode information behind the scenes. Aside from this, the editing is just a <tt>hex editing</> - You move the cursor in the current block of the file by using <tt>next</> and <tt>prev</>, move between blocks by <tt>nextblock</> and <tt>prevblock</>, and make changes by the <tt>set</> command. Note that the set command is overridden here - There are no variables. The <tt>writedata</> command will update the current block to the disk. Reaching a file can be done by using the <tt>file</> command from its inode. The <tt>inode</> can be reached by any other means, for example, by the <tt>cd</> command, if you know the file name. The status window will indicate: <itemize> <item> The global block number. <item> The internal file block number. <item> The file offset. <item> The file size. <item> The file inode number. <item> The indirection level - Whether it is a direct block (0), indirect (1), etc. </itemize> The main data window will display the file either in hex mode or in text mode, select-able by the <tt>display</> command. In hex mode, EXT2ED will display offsets in the current block, along with a text and hex dump of the current block. In either case the <tt>current place</> will be highlighted. In the hex mode it will be always highlighted, while in the text mode it will be highlighted if the character is display-able. <sect1>block <tscreen><verb> Syntax: block block_num </verb></tscreen> The <tt>block</> command is used to move inside the file. The block_num</> argument is the requested internal file block number. A value of 0 will reach the beginning of the file. <sect1>display <tscreen><verb> Syntax: display [text || hex] </verb></tscreen> The <tt>display</> command changes the display mode of the file. <tt>display hex</> will switch to <tt>hex mode</>, while <tt>display text</> will switch to text mode. The default mode when no <tt>display</> command is issued is <tt>hex mode</>. <sect1>inode <tscreen><verb> Syntax: inode </verb></tscreen> The <tt>inode</> command will return to the inode of the current file. <sect1>next <tscreen><verb> Syntax: next [num] </verb></tscreen> The <tt>next</> command will pass to the next byte in the file. If num</> is supplied, it will pass to the next num</> bytes. <sect1>nextblock <tscreen><verb> Syntax: nextblock [num] </verb></tscreen> The <tt>nextblock</> command will pass to the next block in the file. If num</> is supplied, it will pass to the next num</> blocks. <sect1>prev <tscreen><verb> Syntax: prev [num] </verb></tscreen> The <tt>prev</> command will pass to the previous byte in the file. If num</> is supplied, it will pass to the previous num</> bytes. <sect1>prevblock <tscreen><verb> Syntax: prevblock [num] </verb></tscreen> The <tt>nextblock</> command will pass to the previous block in the file. If num</> is supplied, it will pass to the previous num</> blocks. <sect1>offset <tscreen><verb> Syntax: offset file_offset </verb></tscreen> The <tt>offset</> command will move to the specified offset in the file. <sect1>set <tscreen><verb> Syntax: set [text || hex] arg1 [arg2 arg3 ...] </verb></tscreen> The <tt>file set</> command is working like the <tt>general set command</>, with <tt>type=none</>. There are no variables. <sect1>writedata <tscreen><verb> Syntax: writedata </verb></tscreen> The <tt>writedata</> command will update the current file block in the disk. <sect>The directory When editing a file, EXT2ED analyzes for you both the allocation blocks of the directory entries, and the directory entries. Each directory entry is displayed on one row. You can move the highlighted entry with the usual <tt>next</> and <tt>prev</> commands, and "dive in" with the <tt>followinode</> command. The status window will indicate: <itemize> <item> The directory entry number. <item> The total number of directory entries in this directory. <item> The current global block number. <item> The current offset in the entire directory - When viewing the directory as a continuous file. <item> The inode number of the directory itself. <item> The indirection level - Whether it is a direct block (0), indirect (1), etc. </itemize> <sect1>cd <tscreen><verb> Syntax: cd [path] </verb></tscreen> The <tt>cd</> command is used in the usual meaning, like the global cd command. <itemize> <item> If path</> is not specified, the current directory entry is followed. <item> path</> can be relative to the current directory. <item> path</> can also end up in a file, in which case the file inode will be reached. <item> Symbolic link (fast only, meanwhile) is automatically followed. </itemize> <sect1>entry <tscreen><verb> Syntax: entry [entry_num] </verb></tscreen> The <tt>entry</> command sets entry_num</> as the current directory entry. <sect1>followinode <tscreen><verb> Syntax: followinode </verb></tscreen> The <tt>followinode</> command will move you to the inode pointed by the current directory entry. <sect1>inode <tscreen><verb> Syntax: inode </verb></tscreen> The <tt>inode</> command will return you to the parent inode of the whole directory listing. <sect1>next <tscreen><verb> Syntax: next [num] </verb></tscreen> The <tt>next</> command will pass to the next directory entry. If num</> is supplied, it will pass to the next num</> entries. <sect1>prev <tscreen><verb> Syntax: prev [num] </verb></tscreen> The <tt>prev</> command will pass to the previous directory entry. If num</> is supplied, it will pass to the previous num</> entries. <sect1>writedata <tscreen><verb> Syntax: writedata </verb></tscreen> The <tt>writedata</> command will write the current directory entry to the disk. <sect><label id="block_bitmap">The block allocation bitmap The <tt>block allocation bitmap</> of any block group can be reached from the corresponding group descriptor. You will be offered a bit listing of the entire blocks in the group. The current block will be highlighted and its number will be displayed in the status window. A value of "1" means that the block is allocated, while a value of "0" signals that it is free. The value is also interpreted in the status window. You can use the usual <tt>next/prev</> commands, along with the <tt>allocate/deallocate</> commands. <sect1>allocate <tscreen><verb> Syntax: allocate [num] </verb></tscreen> The <tt>allocate</> command allocates num</> blocks, starting from the highlighted position. If num</> is not specified, num=1</> is assumed. Of-course, no actual change is made until you issue a <tt>writedata</> command. <sect1>deallocate <tscreen><verb> Syntax: deallocate [num] </verb></tscreen> The <tt>deallocate</> command deallocates num</> blocks, starting from the highlighted position. If num</> is not specified, num=1</> is assumed. Of-course, no actual change is made until you issue a <tt>writedata</> command. <tt>writedata</> command. <sect1>entry <tscreen><verb> Syntax: entry [entry_num] </verb></tscreen> The <tt>entry</> command sets the current highlighted block to entry_num</>. <sect1>next <tscreen><verb> Syntax: next [num] </verb></tscreen> The <tt>next</> command will pass to the next bit, which corresponds to the next block. If num</> is supplied, it will pass to the next num</> bits. <sect1>prev <tscreen><verb> Syntax: prev [num] </verb></tscreen> The <tt>prev</> command will pass to the previous bit, which corresponds to the previous block. If num</> is supplied, it will pass to the previous num</> bits. <sect>The inode allocation bitmap The <tt>inode allocation bitmap</> is very similar to the block allocation bitmap explained above. It is also reached from the corresponding group descriptor. Please refer to section <ref id="block_bitmap">. <sect>Filesystem size limitation While an ext2 filesystem has a size limit of <tt>4 TB</>, EXT2ED currently <tt>can't</> handle filesystems which are <tt>bigger than 2 GB</>. I am sorry for the inconvenience. This will hopefully be fixed in future releases. <sect>Copyright EXT2ED is Copyright (C) 1995 Gadi Oxman. EXT2ED is hereby placed under the GPL - Gnu Public License. You are free and welcome to copy, view and modify the sources. My only wish is that my copyright presented above will be left and that a list of the bug fixes, added features, etc, will be provided. The entire EXT2ED project is based, of-course, on the kernel sources. The <tt>ext2.descriptors</> distributed with EXT2ED is a slightly modified version of the main ext2 include file, /usr/include/linux/ext2_fs.h. Follows the original copyright: <tscreen><verb> /* * linux/include/linux/ext2_fs.h * * Copyright (C) 1992, 1993, 1994, 1995 * Remy Card (card@masi.ibp.fr) * Laboratoire MASI - Institut Blaise Pascal * Universite Pierre et Marie Curie (Paris VI) * * from * * linux/include/linux/minix_fs.h * * Copyright (C) 1991, 1992 Linus Torvalds */ </verb></tscreen> <sect>Acknowledgments EXT2ED was constructed as a student project in the software laboratory of the faculty of electrical-engineering in the <tt>Technion - Israel's institute of technology</>. At first, I would like to thank <tt>Avner Lottem</> and <tt>Doctor Ilana David</> for their interest and assistance in this project. I would also like to thank the following people, who were involved in the design and implementation of the ext2 filesystem kernel code and support utilities: <itemize> <item> <tt>Remy Card</> Who designed, implemented and maintains the ext2 filesystem kernel code, and some of the ext2 utilities. Remy Card is also the author of several helpful slides concerning the ext2 filesystem. Specifically, he is the author of <tt>File Management in the Linux Kernel</> and of <tt>The Second Extended File System - Current State, Future Development</>. <item> <tt>Wayne Davison</> Who designed the ext2 filesystem. <item> <tt>Stephen Tweedie</> Who helped designing the ext2 filesystem kernel code and wrote the slides <tt>Optimizations in File Systems</>. <item> <tt>Theodore Ts'o</> Who is the author of several ext2 utilities and of the ext2 library <tt>libext2fs</> (which I didn't use, simply because I didn't know it exists when I started to work on my project). </itemize> Lastly, I would like to thank, of-course, <tt>Linus Torvalds</> and the <tt>Linux community</> for providing all of us with such a great operating system. Please contact me in a case of bug report, suggestions, or just about anything concerning EXT2ED. Enjoy, Gadi Oxman <tgud@tochnapc2.technion.ac.il> Haifa, August 95 </article>